A plain afternoon, I still leisurely leisurely knocking code with tea. Suddenly, a server colleague told me that I was concerned that the interface was being called mechanically, suspecting that someone was using a script to brush the interface (mainly to divert traffic from the platform). What? No, because as far as I know the interface request is encrypted, unless you know the encryption key and encryption method, otherwise it will not be successful, you must feel wrong. However, when a server colleague sent me the interface call log, my luck was completely denied.

Based on the above three points, it can be concluded that there must be a brush interface behavior.

Since the above behavior of brushing the interface is true, it means that the key and encryption method are known to the other party, for the following reasons:

After confirmation, the first point is basically excluded, so only APK is cracked, but the package released by APK has been strengthened and confused, is the other party unshelled? Anyway, try decompiling yourself first. As a result, we decompile from the latest version one by one, and when we decompile to an earlier version, we find that the source code of the utility class that holds the key and encryption is completely exposed.This version has been released without hardening, and the encryption tool class has not been confused. It is not clear whether the encryption key and algorithm are obtained in this way, but there is no doubt that this is a security hole on the client side.

Now that the above problems have been identified, we must try to solve them. First of all, regardless of hardening, how to ensure that sensitive data in the client is not leaked to the maximum extent possible? On the other hand, even if the other side wants to crack, also want to think of ways to build obstacles, increase crack difficulty. Thinking of this, I basically determined a idea: use NDK to put sensitive data and encryption methods into native layer, because the so library generated after compilation of C++ code is a binary file, which will undoubtedly increase the difficulty of cracking. With this feature, you can write client-sensitive data in C++ code to enhance application security. Just do it!!

1. First create the encryption tool class:

2. Generate the corresponding header file com_test_util_httpkeyutil.h

3. Prepare relevant CPP files:To create a JNI directory in the appropriate Module, willcom_test_util_HttpKeyUtil.hCopy it in, and then create itcom_test_util_HttpKeyUtil.cppfile

And that's the end of it? Too yuang too simple!! Although the key and encryption algorithm are written in c++, it seems to be more secure. But what if someone gets the so library generated by c++ code after decomcompiling, and then directly calls the method in the so library to get the key and call the encryption method? It seems that we still need to add a step of identity verification: that is, to authenticate the package name and signature of the application in the native layer, the correct result will be returned only after the verification passes. Here is the code to get the APK package name and signature verification:

The above is the relevant code of the native of this event. As for how to generate so library, you can baidu by yourself. A few points to reflect on from this incident are: